第 24 篇最後那張表，把一個代理的天花板列成五塊：窗口、工具箱、執行路徑、權限、觀點。每一塊旁邊都寫了拆法，但拆開要多付多少，我只留了一句「下一層看實測的數字」。

這一篇進第七層，多代理協作。先講結論：把工作拆給好幾個代理，帳會更貴，而且貴很多。 Anthropic 自己的研究系統，多代理吃的詞元約是聊天的 15 倍，單一代理是 4 倍。拆開買到的是好幾個乾淨的窗口和可以同時跑的子任務。學界量到的結果更兩極，拆得開的任務多代理贏很多，一步接一步的任務拆開反而輸更多。

一個真的拆過的系統

Anthropic 在〈How we built our multi-agent research system〉（2025-06-13，2026-10-09 查）寫了 Claude 研究功能的做法，架構叫協調者與工作者（orchestrator-worker）：一個主代理（lead agent）讀問題、把工作切成幾塊，各交給一個**子代理（subagent）**去查。子代理同時跑，把結論交回主代理彙整。

這是廠商量自己的系統。 評估集是內部的，90.2% 我沒辦法重現。15 倍是使用量，比較接近帳單。

第三列我讀了最久。Anthropic 自己的解讀是，這個結果支持他們把工作分給各有自己窗口的代理，替平行推理多加容量，多代理架構讓超出單一代理極限的任務能用掉更多詞元。一個代理只有一個窗口，第 11 篇講過它每一圈都在重送、越送越長。拆成五個子代理，就是五個從零開始的窗口。

所以第 24 篇那個問題，在這個系統上會更貴，而照 Anthropic 的說法，多花詞元的能力正是它的設計目的。

拆開買到的三樣東西

第一，脈絡隔離（context isolation）。 子代理讀了二十個檔、跑了十次搜尋，原始材料都留在它自己的窗口，交回主代理的只有一段結論。Anthropic 的說法是搜尋的本質是壓縮，子代理替主代理先壓過一遍。對照第 6 篇的四種失效，主窗口少了不需要逐字看的東西，可分心性就少了來源。那一篇把子代理列為官方三種做法之一、說留到第七層，就是這裡。它跟第 14 篇的壓縮差在時機：壓縮是窗口滿了回頭摘要，子代理是一開始就不讓原始材料進來。

第二，平行（parallelization）。 第 21 篇的迴圈一次走一步，三件互不相依的事交給三個子代理就能同時查。Anthropic 說這讓複雜問題的研究時間最多縮短 90%。但主代理目前是同步等的，一批子代理全部做完才往下走，最慢的那一個擋住整個系統。平行省下的只有時間，詞元一個都不會少。

第三，專門化（specialization）。 每個子代理有自己的提示詞、工具和模型。查文件的只拿讀檔工具，跑測試的才拿得到 shell，第 16 篇那種工具多到要靠搜尋的問題就小了。同樣的拆法也能用在安全上：第 20 篇說私有資料、不可信內容、對外通訊三項到齊才致命，拆成幾個代理，就能讓沒有任何一個代理同時握齊三項。

這個拆法比 LLM 老四十年

「把一個大問題交給一群各懂一塊的程式一起解」，在 LLM 之前就是分散式人工智慧的題目。我用三個問題來讀那時候的論文：怎麼切（拆成哪幾塊、拆多細）、誰來做（每一塊交給誰）、結果怎麼流（做完的東西怎麼回到需要它的地方）。這三題各有一篇經典可以對照。

怎麼切：階層式任務網路（hierarchical task network，HTN）。 Erol、Hendler、Nau（AAAI 1994）的摘要第一句說，過去十五年大部分實用的規劃系統，都建立在 HTN 分解上。同一組作者在 UMCP 那篇寫得更具體：化約的規則存成「方法」，一個方法把一個非原始任務對應到一組子任務。拆法的知識，是人事先寫進這些方法裡的。

誰來做：合約網協定（contract net protocol）。 Smith（IEEE Transactions on Computers, 1980）讓任務的分配靠協商：經理（manager）發出任務公告，可以接案的節點自己評估，覺得適合才投標，經理再看標決定交給誰。接下工作的節點還可以把任務再切開、再發包出去。它的出發點是分散式問題求解裡沒有任何一個節點擁有解出整個問題所需的全部資訊。

結果怎麼流：黑板。 Hearsay-II（Erman et al., ACM Computing Surveys, 1980）是語音理解系統，也是一套讓獨立模組合作解題的通用框架。每個知識來源（knowledge source）彼此不直接講話，只透過一個叫黑板（blackboard）的全域資料庫溝通：一個模組把假設寫上黑板，另一個看到符合條件的內容就被觸發，寫的人不用知道誰會讀。被觸發的模組不會全部一起動，還有一個焦點控制（focus of control）機制，挑出當下最有價值的動作先做。這是黑板架構（blackboard architecture）。

三題的答案組起來，就是一個組織的形狀。Horling 與 Lesser（The Knowledge Engineering Review, 2004）整理了多代理系統的九種組織範式，包括階層、團隊、社會、市場、聯盟等，起點是組織設計對系統表現有顯著、量得出來的影響。他們把每一種的優缺點攤開，讓設計的人先看清楚有哪些選擇，再照領域和環境挑。

從一個迴圈，到一張圖

拆開之後，程式比想像中少。主代理還是第 21 篇那個 while，工具清單裡多了一個「交給另一個代理」，而那個工具的執行端是另一個 while：

def worker(task):                        # 子代理：全新的 messages，自己一個窗口
    messages = [task]
    while True:
        reply = model(messages, worker_tools)
        messages.append(reply)
        if reply.stop_reason != "tool_use":
            return reply.text            # 只交回最後那段結論
        messages.append([run(call) for call in reply.tool_calls])

def lead(question):                      # 主代理：工具只有一個 delegate
    messages = [question]
    while True:
        reply = model(messages, [delegate])
        messages.append(reply)
        if reply.stop_reason != "tool_use":
            return reply.text
        tasks = [call.input["task"] for call in reply.tool_calls]
        results = parallel_map(worker, tasks)   # 同一輪開的幾張單同時跑
        messages.append(results)

這是虛擬碼，跟第 21 篇只差兩處：worker 的 messages 是新的，看不到主代理的對話，只交回最後一則文字。主代理同一輪開的幾張 delegate 單同時跑。

第 21 篇說過，那個 while 底下是一張隱性的圖，Hu（2026）主張把它畫成明確的有向無環圖（DAG），Andrew Ng 把這個轉向叫做圖工程（graph engineering）。這段程式是第一步：一個節點變成好幾個，邊就是 task 送下去、結論交回來那兩條線。目前邊還是主代理臨場決定的，把它們事先畫好，是圖工程接下來要做的事。

Claude 上的兩種做法

Claude Code：子代理，交回一段摘要

Claude Code 的子代理是 .claude/agents/ 底下的一個 Markdown 檔，name 和 description 必填，其他欄位決定工具和模型。官方範例：

---
name: code-reviewer
description: Reviews code for quality and best practices
tools: Read, Glob, Grep
model: sonnet
---

You are a code reviewer. When invoked, analyze the code and provide
specific, actionable feedback on quality, security, and best practices.

每個子代理在自己的窗口裡跑，做完只把摘要交回主對話。Claude 看到某件工作符合 description，就交給它。子代理預設可以再開子代理，最多到主對話底下三層（2026-10-09 查）。這是派工那一型。

Managed Agents：各自的窗口，共用一個檔案系統

API 這邊，Managed Agents 的多代理協作（beta，標頭 managed-agents-2026-04-01，2026-10-09 查）換了一種切法：所有代理共用同一個沙箱、檔案系統和憑證，但各自跑在自己的工作階段執行緒（session thread） 裡，對話歷史、工具和 MCP 伺服器分開。協調者用 multiagent 列出可以交辦的代理（官方範例）：

coordinator = client.beta.agents.create(
    name="Engineering Lead",
    model="claude-opus-5-5",
    system="You coordinate engineering work. Delegate code review to the reviewer agent and test writing to the test agent.",
    tools=[{"type": "agent_toolset_20260401"}],
    multiagent={
        "type": "coordinator",
        "agents": [
            {"type": "agent", "id": reviewer_agent.id},
            {"type": "agent", "id": test_writer_agent.id},
        ],
    },
)

跟 Claude Code 不一樣的地方：

• 窗口分開，檔案共用。 產物可以寫成檔案，誰需要誰去讀。但文件描述的下一步，是由協調者交辦決定的，沒有「看到某個檔案就觸發」的機制，所以它是派工加上一個共用的資料區。
• 執行緒會留著。 協調者可以追問之前叫過的代理，它記得自己前面每一輪。上面那個 worker 則是做完就結束。
• 只能交辦一層。 名單最多 20 個代理，同時最多 25 條執行緒，一份工作階段預算大家分。
• 權限照代理分。 MCP 伺服器宣告在各代理自己的定義裡。在 auto 權限模式下，協調者傳給子代理的訊息不算使用者的意圖，不能替子代理放行工具呼叫。就算協調者讀到不可信的內容、被注入了指令，它對子代理說的話也不會變成放行的理由。

今天的框架怎麼回答這三個問題

拿那三個問題，今天的框架可以放在同一張表上：

CrewAI、OpenAI Agents SDK 也落在這張表裡，這裡只列名字。

排起來，有三件事可以對照回前面那三篇經典：

• 怎麼切，大致分三種。 事先寫在流程或程式裡（MetaGPT 的 SOP、LangGraph 的圖），交給協調者臨場決定（Claude Code、Managed Agents、HuggingGPT），或在對話裡一步一步長出來（CAMEL、AutoGen）。
• 臨場挑人的，都是讀描述。 Claude Code 看子代理的 description，HuggingGPT 看模型的功能描述。合約網的方向相反，是工作者自己評估、覺得適合才投標。
• 可以再發包。 合約網接下工作的節點可以再切、再發包，Claude Code 的子代理也可以再開子代理，Managed Agents 則只准一層。

不管哪一種，能被叫的代理、各自能做什麼，都是人事先定義好的。

子代理只拿得到你寫給它的那幾句

脈絡隔離有反面。子代理看不到主代理的對話，它知道的就只有那段 task。主代理想了半天卻沒寫進去的，子代理都不知道。

Anthropic 一開始讓主代理給簡短的指示，結果子代理重複做同一件事、留下沒人查的空白，或找不到該找的資料。後來每個子代理都要拿到四樣東西：目標、輸出格式、該用哪些工具和來源、清楚的範圍邊界。第 2 篇的結論是模型只看得到你送進去的東西，好的那個問法多做的就是給情境、指定格式、講明不要什麼。主代理寫給子代理的 task 也是一份提示詞，同一條規則照樣成立，只是寫的人換成了主代理，而且中間沒有人看。在 Claude Code 裡叫子代理去查東西，這四樣可以直接當格式。

什麼時候拆了只是更貴

Anthropic 列的不適合有三種：每個代理都需要同一份脈絡、代理之間依賴很多，以及大部分寫程式的任務，因為能平行的部分比研究少。還有一條是錢：任務要值得那筆多出來的詞元。學界有兩篇量得更硬。

Kim et al.（arXiv 2025，2026-04 修訂）用三個模型家族、六個代理評測，比了單一代理和四種多代理接法，共 260 種組合。多代理相對於單一代理，從拆得開的財務推理 +80.8%，到一步接一步的規劃 −70.0%。單一代理本來就夠好時，協調的好處遞減，工具多的任務協調開銷比較重。他們的預測模型對沒看過的組合有 87% 能挑中最好的架構。

Wang et al.（arXiv 2024）發現提示詞寫得好的單一代理，幾乎追得上最好的多代理討論，多代理只在提示詞裡沒有範例時才贏。我的讀法是，對照第 3 篇的情境學習，在他們測的推理題上，多開幾個代理去討論，買到的效果可能跟補上幾個範例差不多。

我把它收成一個問題：每個子任務的 task，能不能在還沒看到其他子任務的結果之前就寫出來？ 寫得出來，它們真的獨立，比較接近 Kim 那篇拆得開的那一類任務。寫不出來，它們之間有依賴，比較接近一步接一步的那一類，拆開只是讓好幾個代理來回傳話。寫得出來的話，再問一次：把單一代理的提示詞寫好、補上範例，是不是就夠了。

這麼做的代價

第一，詞元是倍數的。 聊天的 15 倍、單一代理的將近 4 倍。平行只省時間。

第二，交接會掉東西。 子代理只知道 task 裡寫的，主代理只看到交回的摘要。共用檔案系統補得了一部分，但寫進去的東西誰讀了、讀懂沒有，又是另一筆帳。

第三，拆錯了會更差。 一步接一步的任務拆開，Kim 那篇量到最多掉 70%。最慢的子代理還會拖住整批。

這一篇多了什麼，又多付了什麼

多了什麼能力：知道多代理買到的是脈絡隔離、平行和專門化，會用「怎麼切、誰來做、結果怎麼流」比較任何一種拆法，看得懂協調者與工作者就是一個 while 呼叫另一個 while，會用 Claude Code 的 .claude/agents/ 和 Managed Agents 的 multiagent 定義多個代理，並用「子任務能不能先寫出來」判斷該不該拆。

多付了什麼代價：約 15 倍於聊天的詞元、掉在兩個窗口之間的脈絡，以及拆錯任務時比單一代理更差的結果。

下一篇

主代理要怎麼把一件事切開、子代理的結果又要用什麼形狀交回來，才不會各做各的、做完拼不起來？

下一篇把協調者和工作者之間的那幾條邊攤開來看。

延伸閱讀

論文

• Towards a Science of Scaling Agent Systems（Kim et al., 2025）：什麼任務該拆、什麼任務拆了更差。
• Rethinking the Bounds of LLM Reasoning: Are Multi-Agent Discussions the Key?（Wang et al., 2024）：寫好提示詞的單一代理對上多代理討論。
• A survey of multi-agent organizational paradigms（Horling & Lesser, 2004）：多代理系統的九種組織範式。
• The Contract Net Protocol（Smith, 1980）與 The Hearsay-II Speech-Understanding System（Erman et al., 1980）：派工與黑板的原型。

官方文件

• How we built our multi-agent research system（Anthropic, 2025）：90.2% 與 15 倍的出處，以及寫給子代理的指示怎麼改。
• Multiagent orchestration（Claude 官方文件）：Managed Agents 的協調者名單、執行緒與共用檔案系統。
• Create custom subagents（Claude Code 官方文件）：子代理的檔案格式與欄位。